Proyecto eMERGENCYMAP
Integrantes:
- Constanza acosta jara. |rol usm: 202330019-5
- josefa castillo carrasco. |rol usm: 202430002-4
- rodrigo hernandez julio. |rol usm: 202221053-2
- ignacio Torres oda. |rol
usm: 202221054-0
FECHA: 01 de julio, 2026.
ASIGNATURA: elo329 (Diseño y
programación orientados a objetos).
PROFESOR: agustín gonzalez.
Descripción del
problema a abordar
En
entornos como campus universitarios grandes (Ej. UTFSM), la gestión de
incidentes y emergencias suele centralizarse en canales verbales analógicos
(tales como de forma presencial o llamadas telefónicas). Sin embargo, los
operadores carecen de herramientas visuales dinámicas para registrar, mapear y
hacer seguimiento de los problemas en tiempo real a medida que son reportados
por la comunidad (por medio de llamadas o personalmente). Los sistemas
tradicionales basados puramente en texto y llamadas ralentizan el diagnóstico
situacional como también la toma de decisiones ante eventos complejos.
análisis del
problema
En
el contexto de la UTFSM, existe la necesidad de una aplicación central de
control con una interfaz gráfica interactiva que permita al operador (guardia)
"marcar" geográficamente un incidente mediante una pulsación (clic)
directo sobre el plano digital del recinto, para así mejorar la conexión
operativa entre la recepción del reporte y su representación visual. Nuestro
sistema automatiza la activación de alarmas visuales y sonoras en la central,
mantener un control estricto de qué emergencias siguen activas, permitir su
desactivación manual una vez resueltas y almacenar un historial diario para
auditorías posteriores sin que los datos se pierdan al cerrar el programa.
A
continuación, se presentan los entes que participan en el problema:
·
Guardia (operador): Ente
interno y usuario principal del sistema. Interactúa
con la interfaz gráfica para registrar incidentes mediante coordenadas
geoespaciales (clic directo sobre el plano digital del recinto), realiza la
monitorización en pantalla y desactiva manualmente las alertas una vez
resueltas en terreno.
·
Subsistema Multimedia
(Alertas): Componente
interno encargado de automatizar los estímulos visuales y sonoros de la central. Modifica
dinámicamente el estado de la interfaz mediante marcadores parpadeantes y
desencadena alarmas acústicas en tiempo de ejecución de manera concurrente al
evento.
·
Módulo de Persistencia de Datos: Mecanismo interno que
interactúa con el sistema de archivos de la máquina. Su función es
estructurar y almacenar permanentemente un historial diario de las emergencias
resueltas, previniendo la pérdida de información tras el cierre de la
aplicación.
·
Comunidad
Universitaria: Ente
externo al software que actúa como el disparador del flujo operativo al
notificar los incidentes a la central de forma analógica (llamadas o
presencial). Define las
variables de entrada de la situación (tipo de incidente, criticidad y
localización aproximada).
Definición
del sistema:
El sistema nominado “EmergencyMAP” se define como una aplicación de escritorio interactiva
para el control centralizado de emergencias, construida bajo el
paradigma de Programación Orientada a Objetos. La lógica está delimitada por la
interfaz gráfica que procesa pulsaciones del mouse para la captura de
coordenadas 
sobre un mapa
digitalizado del campus. El sistema se encarga de coordinar de manera síncrona los
estados de las alertas, la activación/desactivación de estímulos multimedia y
la gestión de la persistencia de datos en archivos locales antes de la
finalización de su ciclo de vida.
Interacciones
con el medio externo:
La frontera entre el
sistema y su entorno externo se gestiona mediante dos flujos de interacción
principales:
1. Flujo
de Entrada: La comunidad universitaria (medio
externo) genera un reporte verbal (presencial o vía telefónica). El Guardia
(operador) actúa como puente traduciendo este estímulo externo en datos
digitales mediante la pulsación del mouse sobre la pantalla, lo que gatilla la
instanciación dinámica de los objetos de emergencia dentro del sistema.
2. Flujo
de Salida: Una vez que una emergencia es
marcada como "Resuelta" por el operador, el sistema interactúa con el
medio externo (el sistema operativo y el disco duro de la computadora)
inyectando flujos de salida de texto (I/O) para escribir y consolidar el
historial diario en un archivo de texto (.txt) local
de forma permanente.
Definición de
requerimientos
El
sistema desarrollado ha considerado los siguientes casos de uso:
CU001:
Registrar emergencia
|
Nombre |
Registrar emergencia. |
||||||||||||||||||||||||
|
Propósito |
Permitir el registro de una nueva emergencia
dentro del campus para su monitoreo y gestión. |
||||||||||||||||||||||||
|
Actores |
Guardia. |
||||||||||||||||||||||||
|
Pre-condiciones |
El sistema de monitoreo debe estar activo y el
mapa del campus correctamente cargado. |
||||||||||||||||||||||||
|
Evento |
El guardia recibe un reporte de emergencia. |
||||||||||||||||||||||||
|
Curso normal de eventos |
|
||||||||||||||||||||||||
|
Curso alternativo de eventos |
7.1. Si la alarma sonora ya se encuentra activa,
se omite el paso 7 del flujo principal. |
||||||||||||||||||||||||
|
Requerimientos no funcionales |
El marcador visual y la alerta sonora deben
activarse en un tiempo de respuesta menor a 1 segundo tras el registro. |
||||||||||||||||||||||||
|
Autor |
Desarrolladores. |
Tabla 1: Descripción del
caso de uso “Registrar emergencia”.
CU002:
Resolver emergencia
|
Nombre |
Resolver emergencia. |
||||||||||||||||||
|
Propósito |
Permitir que una emergencia activa sea marcada
como resuelta. |
||||||||||||||||||
|
Actores |
Guardia. |
||||||||||||||||||
|
Pre-condiciones |
Debe existir al menos una emergencia activa
registrada y visible en el sistema. |
||||||||||||||||||
|
Evento |
El guardia decide dar por finalizada la gestión de
una emergencia. |
||||||||||||||||||
|
Curso normal de eventos |
|
||||||||||||||||||
|
Curso alternativo de eventos |
4.1. Si quedan otros incidentes activos en el
sistema, la alarma sonora continúa encendida. |
||||||||||||||||||
|
Requerimientos no funcionales |
La actualización del estado y el cese de las
alertas visuales deben ser inmediatos. |
||||||||||||||||||
|
Autor |
Desarrolladores. |
Tabla 2: Descripción del
caso de uso “Resolver emergencia”.
CU003:
Detener programa y consultar historial
|
Nombre |
Detener programa y consultar historial. |
|||||||||||||||||||||
|
Propósito |
Guardar los registros del día, visualizar el
historial de emergencias resueltas y finalizar la ejecución de la aplicación. |
|||||||||||||||||||||
|
Actores |
Guardia. |
|||||||||||||||||||||
|
Pre-condiciones |
La aplicación se encuentra en ejecución y
recopilando datos de la jornada. |
|||||||||||||||||||||
|
Evento |
El guardia presiona el botón “STOP” para finalizar
el monitoreo. |
|||||||||||||||||||||
|
Curso normal de eventos |
|
|||||||||||||||||||||
|
Curso alternativo de eventos |
2.1. Si ocurre un error al escribir en el archivo
físico, se notifica un error de persistencia antes de intentar continuar. |
|||||||||||||||||||||
|
Requerimientos no funcionales |
La persistencia en el archivo físico debe
realizarse garantizando la integridad de los datos de la sesión actual. |
|||||||||||||||||||||
|
Autor |
Desarrolladores. |
Tabla 3: Descripción del
caso de uso “Detener programa y consultar historial”.
Diseño
A
continuación, presentamos el diagrama de clases de este proyecto:
Figura
1: Diagrama de clases del programa EmergencyMAP.
Adicionalmente,
se han confeccionado los siguientes diagramas de secuencia para los casos de
uso descritos previamente:
Figura
2: Diagrama de secuencia del caso de uso CU001.
Figura
3: Diagrama de secuencia del caso de uso CU002.
Figura
4: Diagrama de secuencia del caso de uso CU003.
PRUEBAS |
RESULTADOS
Los
resultados finales de nuestro proyecto respecto a los casos de uso planteados
son los siguientes:
- CU001:
Registrar emergencia.
Figura 5: Para hacer el registro de la emergencia, se
hace clic en el mapa en el edificio donde se ha reportado una emergencia y
selecciona el tipo de emergencia.
Figura 6: Luego de seleccionar el tipo de
emergencia, se despliega una ventana para ingresar la descripción del
incidente.
Figura 7: Al
quedar registrado un incidente activo, se observa su información en el panel
lateral, se activa un marcador visual parpadeante y la alarma sonora.
- CU002:
Resolver emergencia.
Figura 8: En esta prueba, se observan varios
incidentes activos en el sistema, en el panel lateral se selecciona la
emergencia que se desea resolver, y luego se presiona la opción “Resolver
seleccionada”.
Figura 9: El incidente que fue seleccionado a
resolver, desaparece de la vista lateral y el marcador visual (color azul) se
desactiva, en este ejemplo, al existir otras emergencias activas, la alarma
sonora sigue activa.
- CU003:
Detener programa y consultar historial.
Figura 10: Al finalizar el programa con el botón
“STOP”, se presenta la ventana emergente con el registro de los incidentes del
día, luego, al presionar “Aceptar” se cierra el programa.
VERSIÓN
COMPRIMIDA DEL CÓDIGO DESARROLLADO
Puede acceder a la versión comprimida (descargable)
del proyecto mediante el siguiente enlace:
Además, se proporciona el enlace al repositorio
donde se desarrolló el proyecto: